@rdimascio - I noticed a strange bug here. The navigation component should not run unless the selectors array matches, but it seems to run regardless. Do you mind taking a look?

Thanks for putting this together @dainemawer! I fixed the bug you mentioned, cleaned up the architecture a bit, added error handling and some documentation. This is looking good to me.

cc @joesnellpdx @devinle @nicholasio @fabiankaegy

@rdimascio @dainemawer this is looking good to me. Nice and clean - easy to follow. I also like the ability to pass a custom callback. Well done!

Per discussion with @rdimascio ...

Is this something we want to include in 90% of our projects, or are there particular use cases that would trigger the usage of import-and-run?

If it is not something we want to have as default, do we consider one of the following?:

• Add as an enhancements section in the README - with guidance / examples
• Add a new enhancements doc - link to it in the README - and include guidance / examples for this
• Add an examples directory in the project that is not included with references in the README file / comments
• Add to existing architecture, but comment out with comment guidance when/ how to activate (and add to README)

Either way, there needs to be more clear guidance and documentation for engineers if this is implemented.

@devinle @dainemawer

@nicholasio I would think that script parse and execution time on page load would result in a worse user experience and CWV scores than network requests. I don't have any benchmarks for this either (and @dainemawer can probably provide more insight here) but I believe the implementation for this approach (when and even how to use it) will larger depend on project architecture. I'm in agreement that there needs to be more clear guidance and documentation on this.

xecution time on page load would result in a worse user experience and CWV scores than network requests. I don't have any benchmarks for this either (and @dainemawer can probably provide more insight here) but I believe the implementation for this approach (when and even how to use it) will larger depend on project architecture. I'm in agreement that there needs to be more clear guidance and documentation on this.

You're right but it depends on what you're code splitting. Every optimization comes with an overhead cost. Finding the balance is what we're missing here. We're all on the same page we need more documentation and guidance here 👍

What are we thinking in terms of recommendations for this?

Are we going to essentially code split every single front-end component?

I do not think code-splitting every single front-end component is worth it. There's an overhead of making an additional call to load the JS. If we ever ship something like this I feel we need more guidance around when to use it. While I do not have any benchmark to back me up here I do not think code-splitting very small components would actually give any meaningful improvement, while potentially making things a little worse. We should also be mindful of CLS, if every single front-end component is lazy-loaded, this might mean we're delaying fully rendering stuff on the front end which could cause content shifting

@nicholasio - yeah I agree here, I don't think the intention is to code-split every component. What this PR lacks, as @joesnellpdx mentioned above, is documentation is going forward. The idea here should be to code-split out:

• Any resource heavy functions / components - potentially components requiring third-party libs like lodash, moment etc.
• Any scripts that do not need to be loaded in the bundle on initial load - chat libs, cookie banners etc.

I will add some guidance here. I'll also clean up this entry file so that its more instructional.

In general, benchmarks are a bit all over the place. They are specific to the nature of the site as well. The overall strategy here is to offload any components and scripts that are not absolutely needed for a good user experience on initial load - or above the fold.

An example of this would be something along the lines of:

1. We may write a component in JS for the Navigation. That JS should not be lazy-loaded. It's imperative for good UX on initial load.
2. A cookie banner though, whose presence is not in the flow of the document, and does not contribute to important user experience.

Doing this above, and identifying elements with the above nature, means we can keep the byte size of our bundle low.